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Abstract:  Starting  with  a  small  language  designed  by  Dijkstra,  a 
language  is  developed  in  which  the  variable  is  replaced  by  named 
constants  and  parameters.  Based  partially  on  Hehner’s 
modification  of  Dijkstra's  language,  the  language  is  simpler  than 
either  the  original  or  the  modification,  and  yet  is  no  less  powerful. 
Moreover,  more  properties  of  a  program  are  static  in  the  new 
language. 
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1.  Introduction 

A  program  represents  a  class  of  possible  computations,  with  (at  least)  one 
computation  for  each  different  set  of  inputs.  To  understand  a  program,  we  must 
understand  the  whole  of  this  possibly  infinite  class.  Clearly,  to  master  the  complexity 
of  a  program,  we  must  study  the  program  in  a  way  that  does  not  require  studying  the 
individual  computations. 

If  we  can  assign  meanings  to  a  program  and  its  components  textually,  we  have 
succeeded  in  analyzing  it  statically  (that  is,  for  all  computations).  This  is  what  all 
non-operational  methods  attempt  to  do. 

Perhaps  the  most  successful  non-operational  technique  for  reasoning  about 
programs  (and  languages)  has  been  the  axiomatic  method  of  Hoare  [69].  While  some 
language  features  are  hard  to  describe  axiomatic  ally,  this  is  generally  due  to  an  inabil¬ 
ity  to  characterize  these  features  statically.  Complex  control-flow  constructs  and 
aliasing  present  particular  problems.  The  simplest  solution  has  been  to  design 
languages  without  such  features,  although  the  results  can  be  somewhat  austere. 

Dijkstra  [76]  designed  a  very  simple  language  in  which  to  develop  and  present 
algorithms.  He  included  a  feature  only  when  compelled  to,  and  then  only  in  a  form  that 
could  easily  be  axiomatized. 

During  the  execution  of  a  program,  the  result  of  referencing  a  variable  that 
has  not  been  initialized  is  unpredictable  and  therefore  usually  meaningless.  In  most 
languages,  determining  that  a  referenced  variable  has  been  initialized  cannot,  in  gen¬ 
eral,  be  done  statically.  Experience  has  shown  this  to  be  a  major  source  of  program¬ 
ming  errors.  Dijkstra  designed  his  language  in  such  a  way  that  initialization  analysis 
can  always  be  done  statically. 

Hehner  [79]  replaced  Dijkstra’s  do  statement  with  recursion,  simplifying  the 
axiomatic  semantics  of  the  language  in  the  process.  Hehner  called  his  simple  parame¬ 
terless  routines  refinements ,  by  analogy  with  Dijkstra’s  informal  use  of  a  similar 
mechanism. 

We  propose  to  simplify  Hehner’s  language  still  further:  once  a  variable  has 
been  initialized,  we  do  not  allow  it  to  change.  To  replace  re-assignment,  we  add  a  sim¬ 
ple  parameter  mechanism  to  Hehner’s  refinements.  As  a  result,  for  every  reference  to 
a  variable,  it  can  be  determined  statically  which  (possibly  composite)  statement 
assigned  it  its  value.  As  might  be  expected,  our  assignment  axiom  is  much  simpler 
than  previous  ones.  The  key  advantage  of  our  language  is  reflected  in  the  fact  that  all 
predicates  and  expressions  are  invariant  during  the  lifetime  of  their  named  constants. 

Even  with  such  a  drastic  change  to  Dijkstra’s  language,  his  proof  techniques 
and  programming  methodology  can  be  carried  over,  and  even  simplified.  Moreover,  we 
can  transform  any  program  in  his  language  to  ours. 

In  the  next  sections  we  describe  Dijkstra's  language  and  Hehner’s 
modifications.  We  then  examine  what  the  variable  is  used  for,  and,  based  on  Hehner’s 
modifications,  how  the  variable  can  be  replaced.  We  show  how,  in  the  new  language,  the 
strongest  postcondition  predicate  transformer  can  be  useful  in  addition  to  the  weakest 
precondition.  A  sample  program  development  highlights  similarities  and  differences 
between  Dijkstra’s  and  our  languages.  We  discuss  the  main  problem  for  efficient  imple¬ 
mentation,  large  values.  We  conclude  by  showing  how  our  language  is  an  interface 
between  the  Algol  and  LISP  cultures. 
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2.  Dijkstra’s  Language 

Dijkstra’s  basic  language  contains  three  statements:  assignment,  if,  and  do. 
The  assignment  statement  has  its  usual  meaning,  although  multiple  assignments  are 
allowed.  The  language  is  distinguished  by  the  introduction  of  guarded  commands.  A 
guarded  command  is  a  sequence  of  statements  preceded  by  a  predicate  (the  guard) 
which  must  be  true  before  the  statement  sequence  may  be  executed.  The  if  and  do 
statements  consist  of  if  fi  and  do  od  brackets  respectively,  around  a  set  of  guarded 
commands.  A  guard  is  separated  from  its  statement  list  by  an  arrow  and  guarded  com- 
mands  are  separated  by  ”11”.  When  an  if  statement  is  executed,  exactly  one  of  the 
guarded  commands  of  the  if  that  has  a  true  guard  is  selected  and  the  associated  state¬ 
ment  sequence  is  executed.  When  a  do  statement  is  executed,  repeatedly  a  guarded 
command  with  a  true  guard  is  selected  and  executed  until  no  guard  is  true.  For  exam¬ 
ple,  the  following  program  sets  the  variable  ”g”  to  the  GCD  of  “X”  and  “Y”. 

x,y:=X,Y; 

do  x>y  ->  x:=x-y 
D  y>x  ->  y:= y-x 

od; 

g:=x 

In  a  later  chapter,  Dijkstra  added  variable  declarations,  begin  blocks  and 
scope  rules  to  his  language.  The  scope  mechanism  is  complicated  and  wordy,  but  it 
allows  great  control  over  inheritance  of  names  and  static  detection  of  uninitialized 
variables. 


Dijkstra  requires  that  before  a  variable  may  be  referenced  there  must  be  a 
single  (possibly  composite)  statement  guaranteed  to  initialize  it.  If  this  statement  is 
an  assignment,  compliance  is  obvious.  If  the  statement  is  an  if,  all  of  its  guarded  com¬ 
mands  must  initialize  the  variable.  In  the  case  of  begin  blocks,  some  constituent  state¬ 
ment  must  do  the  initializing.  Only  the  do  statement  is  not  allowed  to  initialize  a  vari¬ 
able,  because  there  is  no  guarantee  any  of  its  guarded  commands  will  be  executed. 

The  declaration  of  a  variable  says  whether  the  variable  is  global  to  the  scope 
and  already  initialized  (glo),  or  global  and  not  yet  initialized  (vir  for  virgin),  or  local 
(pri  for  private).  It  also  states  whether  the  variable  can  be  changed  after  initialization 
(var)  or  not  (con).  The  word  vir  in  an  assignment  means  that  this  is  an  initializing 
assignment. 

The  GCD  program  with  scope  declarations  added  is: 

begin  glocon  X,Y;  vireon  g;  privar  x,y; 
x  vir,  y  vir  :=  X,  Y; 
do  x>y  ->  x:=x-y 
II  y>x  ->  y:=y-x 
od; 

g  vir:  =  x 

end 

In  the  example,  “g”  is  declared  to  be  a  vireon,  which  means  that  it  comes  from  an 
outer  scope,  this  routine  must  initialize  it,  and  the  routine  cannot  change  it  after  ini¬ 
tializing  it.  Thus  the  assignment  to  “g"  is  the  initializing  assignment  and  is  marked 
with  vir. 

Arrays  contain  multiple  values.  To  ensure  that  uninitialized  values  do  not 
arise,  the  above  scheme  requires  that  an  entire  array  be  initialized  at  once.  To  reduce 
the  impact  of  this,  Dijkstra  allows  arrays  to  grow  as  new  elements  are  computed.  To 
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allow  aliasing  to  be  detected,  an  array  value  is  thought  of  as  a  single  composite  value 
and  an  array  variable  as  a  single  variable.  Assigning  to  an  element  of  an  array  variable 
is  then  conceptually  a  re-assignment  to  the  whole  array. 


3.  Hehner’s  Proposal 

Hehner  observed  that  Dijkstra  used  a  rudimentary  refinement  mechanism 
without  formalizing  it.  A  new  operation  could  be  invoked,  and  later  refined.  The  subse¬ 
quent  refinement  would  then  break  the  operation  down  into  a  sequence  of  statements 
with  the  required  effect.  All  variables  were  global  and  were  inherited  by  refinements. 

Unlike  Dijkstra,  Hehner  allowed  refinements  to  be  recursive.  This  made  the 
do  statement  unnecessary,  and  Hehner  excluded  it,  arguing  that  programs  were 
clearer  as  a  result. 

A  GCD  program  written  in  Hehner’s  language,  for  example,  is  an  initializing 
assignment  and  then  a  refinement  call: 

x,y:=X,Y; 

"establish  g  =  GCD(x,y),  maintain  GCD(x,y)=GCD(X,Y)" 
along  with  the  definition  of  the  refinement: 

"establish  g=GCD(x,y),  maintain  GCD(x,y)=GCD(X,Y)”: 
if  x=y  ->  g:=x 
D  x>y  ->  x:=x-y; 

"establish  g=GCD(x,y),  maintain  GCD(x,y)=GCD(X,Y)” 

D  y>x  -»  xy:=y—  x; 

"establish  g=GCD(x,y),  maintain  GCD(x,y)=GCD(X,Y)" 
fi 

Note  that  when  a  repetition  is  required,  it  must  be  explicitly  specified.  In  the  GCD 
refinement,  the  first  guarded  command  does  not  recurse  and  is  therefore  the  one  that 
causes  the  repetition  to  terminate.  A  do  statement,  on  the  other  hand,  stops  by 
default,  when  no  guard  is  true.  This  feature  of  Hehner’s  language  allows  structures 
equivalent  to  "intermediate  exits"  and  "deep  exits"  [Hehner  79]. 

If  none  of  the  guards  of  an  if  is  true,  the  program  aborts.  Thus  a  program  in 
an  unexpected  state  will  often  abort  when  it  encounters  an  if.  This  "robustness"  pro¬ 
perty  is  not  shared  by  the  do  statement,  which  terminates  normally  when  no  guard  is 
true.  Programs  in  Hehner’s  language,  because  they  do  not  use  the  do,  have  the  poten¬ 
tial  of  being  more  robust. 

A  straightforward  transformation  turns  a  do  statement  into  a  recursive 
refinement.  The  body  of  the  refinement  is  an  if  statement  containing  the  guarded 
commands  of  the  do,  but  with  a  recursive  call  added  at  the  end  of  each.  The  if  needs 
one  more  guarded  command  to  end  the  repetition.  Its  guard  is  the  negation  of  the  dis¬ 
junction  of  all  the  other  guards,  and  its  action  is  skip,  the  null  command.  Note  that  no 
node  splitting  (duplicating  of  code  fragments)  is  required  by  the  transformation.  Thus, 
for  example: 

do  x>y  -»  x:=x-y 
B  y>x  ->  y:=y-x 

od 


becomes 
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"loop” 

"loop”: 

if  x>y  -»  x:=x-y;  “loop" 
0  y>x  -»  y r=y-x;  “loop” 
D  non(x>y  j  y>x)  -»  skip 

fi 


No  suggestion  is  made  that  the  program  resulting  from  this  transformation  is 
an  improvement  over  the  original.  Indeed,  when  we  translated  the  GCD  program,  we 
did  not  do  so  by  the  described  transformation.  The  existence  of  this  transformation, 
however,  shows  that  Hehner’s  language  is  at  least  as  powerful  as  Dijkstra's:  everything 
written  with  do  loops  can  be  written  fairly  straightforwardly  with  refinements. 

The  recursion  resulting  from  this  transformation  need  be  no  more  expensive 
than  the  do  to  implement.  All  recursion  used  in  place  of  do  loops  involves  last  action 
calls.  A  call  is  last  action  if,  whenever  it  is  executed,  it  is  the  last  statement  executed 
in  the  refinement  in  which  it  occurs.  A  last  action  call  can  be  implemented  as  a  branch 
since  there  is  no  need  to  return  to  finish  executing  the  refinement.  Last  action  recur¬ 
sion  is  also  known  as  tail  recursion  [Steele  77]. 

Although  every  program  in  Dijkstra’s  language  can  be  transformed  simply 
into  Hehner's  language,  the  converse  is  not  true.  Every  do  loop  is  equivalent  to  some 
last  action  recursion,  but  not  all  recursion  in  Hehner’s  notation  is  last  action.  The  fol¬ 
lowing  (inefficient)  refinement  to  calculate  r=n!  illustrates  this: 

"establish  r=n!”: 

if  n=0  ->  r:=l 
0  n>0  ->  n:=n- 1; 

"establish  r=n!”; 
n:=n+l; 
r:=rxn 
fi 

Since  there  is  no  parameter  or  local  variable  mechanism  in  Hehner’s  language,  non¬ 
last-action  recursion  is  clumsy  and  probably  not  very  useful. 


4.  What  is  the  Variable  Used  For? 

A  variable  is  a  holder  for  a  value  and  is  used  to  carry  a  value  between  state¬ 
ments  in  a  program.  The  use  of  a  particular  variable  falls  into  one  of  several  patterns. 

Some  variables  are  used  to  hold  only  one  value  in  their  lifetime.  For  example, 
a  program  might  contain  a  variable  "pi”  initialized  to  3.14159  and  never  changed. 
Similarly,  a  routine  to  calculate  solutions  to  quadratic  equations  might  have  a  local 
variable  "disc”  to  which  it  assigns  the  discriminant  of  the  equation.  In  both  cases,  we 
call  these  variables  named  constants  because  once  assigned  a  value,  they  never 
change.  Note  that  whereas  the  value  of  "pi”  is  constant  throughout  the  running  of  the 
entire  program,  each  invocation  of  the  quadratic  equation  solving  routine  uses  a 
different  incarnation  of  the  named  constant  "disc”. 

A  variable  may  be  assigned  only  one  value  in  its  lifetime  and  yet  appear  in 
more  than  one  assignment  statement.  For  example,  the  following  program  sets  “absx” 
to  the  absolute  value  of  "x”: 
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begin  glocon  x;  vircon  absx; 

if  Xs^O  ->  absx  vir:=x 
D  xSO  ->  absx  vir:=— 
fi 

end 

Only  one  of  the  assignments  will  be  executed  in  an  Invocation  of  this  code.  To  assert 
that  a  variable  will  only  be  assigned  (dynamically)  once,  the  variable  is  declared  as  con. 
This  assertion  can  always  be  checked  statically  since  every  assignment  must  then  be 
an  initializing  assignment,  and,  as  with  Dijkstra’s  language,  the  initializing  assignments 
are  constrained  to  be  statically  checkable.  These  variables  too  are  named  constants. 

A  variable  may  take  on  a  sequence  of  values,  one  at  a  time,  representing  a 
part  of  the  state  of  a  repetition  (a  do  loop  in  Dijkstra’s  language,  or  a  recursive  nest  of 
refinements  in  Hehner’s).  For  example,  in  the  following  program  to  sum  an  array,  the 
variable  “i”  represents  how  far  the  summing  has  gone,  and  “s”  represents  the  sum  up 
to  this  point: 

begin  glocon  a,n;  privar  i,s; 
i  vir:  =  l; 
s  vir:  =  Q; 

do  iSn  -*  i,  s  :=  i+1,  s+a(i)  od 

end 

At  the  start  of  each  execution  of  the  loop,  the  state  is  identical  except  for  the  values  of 
"i”  and  “s”.  (If  the  state  were  completely  identical,  the  loop  would  either  never  start 
or  never  end.) 

A  variable  is  sometimes  assigned  a  sequence  of  values  that  are  only  weakly 
related.  For  example,  a  variable  "x”  might  be  used  to  hold  a  value  temporarily  in 
several  different  places  in  a  program.  This  variable  could  be  replaced  by  several 
different  ones,  one  for  each  distinct  purpose. 

Of  these  patterns  of  variable  usage,  the  only  absolute  need  for  variables  as 
opposed  to  named  constants  is  to  represent  the  state  of  a  repetition.  As  Dijkstra  him¬ 
self  observes,  all  other  variables  can  be  replaced  by  one  or  more  named  constants 
[Dijkstra  76,  p.  87].  Thus  the  variable  is  introduced  to  represent  state  when  textual 
position  is  no  longer  sufficient  (due  to  repetition).  Interestingly,  the  do  is  the  only 
statement  in  which  Dijkstra  forbids  constant  assignment  and  variable  initialization. 


5.  A  New  Approach 

We  propose  to  simplify  Hehner’s  language  further,  by  eliminating  the  variable. 
We  retain  the  assignment  to  initialize  named  constants,  but  since  all  assignments  will 
be  to  “virgins”,  there  is  no  longer  a  need  to  mark  these  specially. 

We  have  no  mechanism,  as  yet,  to  represent  the  state  of  a  repetition.  As  we 
noted,  repetition  cannot  make  progress  without  a  way  of  recording  state.  We  introduce 
a  limited  form  of  parameter  for  this  purpose.  The  parameter  allows  different  values  to 
be  carried  into  different  invocations  of  a  refinement.  These  parameters  are  passed  by 
constant :  a  formal  parameter  has  the  status  of  an  initialized  named  constant.  A  value 
can  be  carried  out  of  a  refinement  as  the  value  of  a  global  named  constant  initialized 
by  the  refinement. 

Our  version  of  the  GCD  computation  is  a  refinement  call: 
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“g:=GCD(x,y)”(X,Y) 
along  with  the  refinement  definition: 


“g:=GCD(x,y)”(x,y): 

if  x=y  -*  g:=x 

0  x>y  “g:  =  GCD(x,y),!(x-y,y) 

D  y>x  ->  “g:  =  GCD(x,y)”(x,y-x) 
fi 

Notice  how  similar  this  is  to  the  version  in  Hehner’s  language.  The  parameters  “x”  and 
“y”  carry  the  current  state  of  the  iteration  into  invocations  of  the  refinement,  while 
the  global  named  constant  “g”  carries  the  GCD  out. 

We  must  supply  a  formal  definition  for  the  parameter  mechanism.  Let  "r”  be 
a  refinement  with  parameter  “x”  and  body  S  (“x”  can  be  thought  of  as  a  single  param¬ 
eter  or  a  vector  of  parameters) 

*‘r”(x):  S 

Further,  let  P  be  the  weakest  precondition  of  statement  S  and  postcondition  Q 
P  =  wp(S,Q) 

We  define  the  weakest  precondition  of  refinement  call  “r”(e)  then  to  be  the  predicate  P 
with  all  free  occurrences  of  formal  parameter  “x”  replaced  by  actual  parameter  "e”: 

wp(“r”(e),Q)  =  P(e/x) 

This  is  in  fact  a  combination  of  Dijkstra’s  assignment  rule  and  Hehner’s  refinement  call 
rule. 

Once  a  named  constant  has  been  given  a  value,  it  cannot  be  given  another 
during  its  lifetime.  Thus,  once  an  expression  involving  named  constants  has  a  value  (as 
opposed  to  being  undefined),  that  value  cannot  be  changed  during  the  lifetime  of  its 
named  constants.  Since  predicates  are  just  expressions,  once  a  predicate  is  esta¬ 
blished,  it  remains  so  during  the  lifetime  of  the  named  constants  occurring  in  it,  no 
matter  what  subsequent  assignments  are  made. 

For  this  last  property  to  hold,  “undefined”  must  not  be  a  legitimate  value  in 
the  system.  Thus,  for  example,  there  can  be  no  operator  ”defined(x)’’  that  returns 
true  if  “x”  has  been  assigned  a  value  and  false  otherwise.  If  this  were  allowed,  the 
predicate  “defined(x)’'  would  change  value  after  an  assignment  to  “x”.  In  fact,  most 
operators  are  strict :  their  results  are  defined  only  if  all  their  operands  are.  The  condi¬ 
tional  logical  operators  are  not  strict  because,  depending  on  their  left  operand,  they 
may  yield  results  completely  independent  of  their  right  operand,  defined  or  not.  We 
require  that  any  operator  (or  refinement)  that  yields  a  value  when  an  operand  is 
undefined,  must  yield  the  same  result  for  all  values  of  the  operand. 


6.  The  Naming  of  Refinements 

Dijkstra  named  his  refinements  in  a  descriptive,  but  informal  way.  He  quoted 
the  names  to  allow  them  to  contain  sentences  and  predicates.  Hehner  used  a  conven¬ 
tion  in  which  names  were  made  up  of  three  kinds  of  predicates:  given,  establish,  and 
maintain.  A  refinement  is  assured  that  its  given  predicate  is  true  whenever  it  is  called. 
The  refinement  is  required  to  make  the  establish  predicate  true  when  it  returns.  A 


-6- 


maintain  predicate  is  both  given  and  to  be  established. 

Although  it  sometimes  causes  cumbersome  names,  we  use  a  modification  of 
Hehner’s  convention.  Because  no  expression  can  change  its  value,  naturally  all  given 
predicates  are  maintained.  Since  our  refinements  are  in  effect  assignments  to  global 
named  constants  their  names  take  the  form  of  a  precondition  (in  brace  brackets)  fol¬ 
lowed  by  an  assignment  to  global  variables,  optionally  followed  by  a  postcondition  on 
the  result.  Usually  a  postcondition  is  not  needed  because  the  assignment  specifies  the 
required  result.  Thus  the  name 

‘‘^exists  n:  x=yxn]  q:=x-ry"(x,y) 

specifies  that  given  that  the  formal  parameter  “x”  is  a  multiple  of  the  formal  parame¬ 
ter  “y”,  the  refinement  will  set  the  global  variable  "q”  to  “x”  divided  by  “y”.  Clearly, 
there  would  be  no  reason  to  write  this  refinement  if  the  program  were  allowed  to  use  a 
built-in  divide  operator.  This  illustrates  how  names  are  written  in  the  assertion 
language,  and  not  in  the  expression  language.  The  details  of  the  assertion  language 
need  not  concern  us  here.  Following  our  new  convention,  our  GCD  program  would  be 
named 


“£x>0  &  y>0]  g:  =  GCD(x,y)”(x,y) 

Our  naming  convention  (like  Hehner’s)  allows  a  very  simple  verification  of  a 
program’s  partial  correctness.  A  refinement's  name  is  also  its  precise  specification. 
One  must  prove  that  each  refinement  lives  up  to  its  name! 

While  proving  a  refinement,  each  call  it  makes  may  be  assumed  to  do  what  its 
name  promises.  Such  a  proof  is  straight-forward  since  no  iteration  is  involved.  Most  of 
the  work,  such  as  inventing  loop  invariants  and  solving  semantic  equations,  is  moved  to 
the  naming  of  refinements. 

To  reflect  the  separation  of  refinement  specification  and  implementation,  we 
redefine  the  refinement  call.  The  meaning  of  a  refinement  call  is  defined  to  be  the 
meaning  of  the  refinement’s  name  after  actual  parameters  have  been  substituted  for 
formals.  Thus,  for  example,  the  meaning  of 


‘‘[exists  n:  x=yxn]  g:=x-ty”(i,j) 


is  defined  to  be 

[exists  n:  i=jxn}  j 

Note  that  the  previous  and  new  definitions  of  refinement  call  are  not  the  same:  the 
body  of  a  refinement  might  well  have  capabilities  beyond  what  the  specification  prom¬ 
ises.  In  this  example,  the  refinement  body  might  yield  a  result  even  if  "x”  were  not  a 
multiple  of  "y”. 


7.  Strongest  Postconditions 

Dijkstra  gave  two  reasons  for  using  weakest  preconditions  instead  of  strongest 
postconditions:  weakest  preconditions  ‘‘seemed  to  give  a  smoother  formalism...  [and] 
...to  do  more  justice  to  the  fact  that  programming  is  a  goal-directed  activity”  [Dijkstra 
76  p.  214].  In  this  section  we  investigate  how,  in  the  new  language,  postconditions  pro¬ 
vide  a  smooth  formalism  too.  While  programming  is  indeed  goal-directed,  we  wish  to 
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use  our  formalism  for  analysis,  as  well  as  synthesis.  We  are  not  discarding  precondi¬ 
tions,  only  adding  postconditions  to  our  toolkit. 

Dijkstra  introduced  ‘'wp(S,R)”  to  denote  the  weakest  precondition  on  the 
state  of  a  machine  such  that  executing  statement  S  in  any  of  these  states  is 
guaranteed  to  terminate  with  the  machine  in  a  state  satisfying  postcondition  R.  A 
predicate  characterizes  (and  is  an  expression  of)  a  set  of  states,  and  can  thus  be  used 
interchangeably  with  that  set  [Hoare  78].  The  weakest  precondition  is  a  predicate 
transformer:  it  transforms  the  postcondition  (a  predicate)  into  a  precondition  (another 
predicate).  There  may  be  many  preconditions  that  would  guarantee  postcondition  R 
after  executing  S;  the  weakest  is  the  most  inclusive,  characterizing  the  complete  set  of 
initial  states  guaranteeing  R.  There  may  be  many  predicates  characterizing  this 
unique  set  of  states,  but  all  are  equivalent. 

To  be  useful,  a  predicate  transformer  should  be  a  simple  transformation  of  its 
predicate  argument,  based  on  its  statement  argument.  For  example,  the  weakest 
precondition  of  the  assignment  x:  =  e  and  postcondition  R  is  just  R  with  all  free 
occurrences  of  x  replaced  by  e: 

wp(x:=e,R)  =  R(e/x) 

Using  this  definition, 

wp(x:  =  3,  x=y  &  y=z)  =  (3=y  &  y=z) 


The  weakest  precondition  of  a  given  statement  maps  postconditions  to 
preconditions.  It  is  natural  to  consider  a  mapping  the  other  way.  A  postcondition  is  a 
predicate  that  is  true  after  executing  a  statement;  the  canonical  postcondition  is  the 
one  that  most  restricts  the  state.  Given  a  statement,  the  strongest  postcondition 
predicate  transformer  sp  maps  a  precondition  into  the  most  restrictive  postcondition. 

Unfortunately,  there  is  no  simple  predicate  transformer  sp  for  the  general 
assignment  statement.  Consider,  for  example,  executing  the  statement  x:=3  in  a  state 
satisfying  “x=y  &  x=z”: 

sp(x=y  &  x=z,  x:  =  3) 

The  result  should  be  “y=z  &  x=3”,  but  how  can  we  express  this  as  a  transformation  of 
the  text  of  the  precondition?  The  only  answer  seems  to  be  to  introduce  "ghost"  vari¬ 
ables  in  predicates  to  represent  the  previous  values  of  variables. 

Our  restricted  form  of  assignment,  however,  has  no  such  problem:  the  named 
constant  being  assigned  has  no  previous  value.  The  strongest  postcondition  of  the 
assignment  is  very  simple: 

sp(R,x:  =  e)  =  R  &  (x=e) 

(Like  the  weakest  precondition,  our  precondition  R  must  imply  that  x  is  a  valid  refer¬ 
ence  and  e  is  a  valid  expression  [Dijkstra  76  p.  28,  Elliott  79  chapter  2].) 

Once  a  strongest  postcondition  transformer  is  defined  for  assignment,  the 
other  language  features  follow  easily.  The  strongest  postcondition  of  an  if  statement  is 
simply  the  disjunction  of  the  strongest  postconditions  of  its  guarded  commands.  For 
example: 


sp(R,  if  gl->sl  D  g2->s2  fi)  =  sp(R  &  gl,  si)  |  sp(R  &  g2,  s2) 
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For  the  if  statement  to  be  valid,  the  precondition  R  must  imply  that  at  least  one  of  the 
guards  is  true.  If  none  of  the  guards  is  true,  both  sides  of  this  equation  reduce  to  false. 

The  strongest  postcondition  of  a  refinement  call  is  simply  the  strongest 
postcondition  of  the  refinement’s  meaning  (that  is,  its  name)  after  parameter  substitu¬ 
tion.  (If  our  naming  convention  were  not  used,  the  strongest  postcondition  would  be 
that  of  the  refinement's  body  after  parameter  substitution.) 

It  should  be  noted  that,  for  all  statements  in  our  language,  the  strongest 
postcondition  is  a  strengthening  of  the  precondition: 

sp(R,  S)  =>  R  for  all  statements  S 

This  is  equivalent  to  the  earlier  statement  that  once  a  predicate  is  established,  it 
remains  true  for  the  lifetime  of  the  named  constants  it  references.  Thus  the 
occurrence  of  a  statement  can  only  add  to  our  static  knowledge. 


8.  What  i9  the  Expressive  Power  of  the  New  Language? 

In  this  section  we  show  that  our  language  has  as  least  the  power  of  Dijkstra’s 
by  describing  how  to  mechanically  translate  any  program  from  Dijkstra’s  to  ours.  We 
make  no  claim  that  this  particular  translation  is  an  improvement.  The  introduction  of 
recursive  refinements  in  place  of  the  do  is  similar  to  the  method  used  for  Hehner’s 
language.  The  main  problem,  of  course,  is  to  eliminate  re-assignment  to  variables.  The 
following  paragraphs  describe  the  translation. 

Re-assignments:  A  statement  that  changes  a  variable’s  value  must  instead  ini¬ 
tialize  a  new  named  constant.  Subsequent  statements  and  predicates  must  then  use 
the  new  named  constant  in  place  of  the  variable.  Thus 

xvir:=a;  x:=b;  y  vir:=x 

becomes 

x:=a;  x2:=b;  y:=x2 

If  statements:  If  any  guarded  command  in  an  if  statement  changes  a  variable, 
each  guarded  command  must  be  made  to  initialize  a  named  constant  to  the  value  that 
the  variable  would  have  had  at  the  command’s  end.  Statements  after  the  if  must  then 
use  this  named  constant  in  place  of  the  variable.  For  example: 

x  vir:=a; 

if  even(x)  ->  skip 
11  odd(x)  -»  x:=x+l 
fi; 

y  vir:=x 


becomes 


x:=a; 

if  even(x)  ->  x2:=x 
D  odd(x)  ->  x2:=x+l 
fi; 

y:=x2 
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Do  statements:  A  do  statement  must  first  be  translated  to  a  recursive 
refinement,  just  as  was  done  to  convert  to  Hehner’s  notation.  By  Dijkstra’s  rules,  all 
global  variables  set  in  a  do  statement  must  have  been  previously  initialized.  If  a  vari¬ 
able  is  changed  in  a  do  statement,  it  must  be  made  a  parameter  of  the  corresponding 
refinement,  allowing  its  value  at  the  end  of  a  guarded  command  to  be  carried  back  to 
the  head  of  the  loop.  The  value  of  the  variable  on  entry  to  the  loop  must  be  used  as  the 
actual  parameter  of  the  initial  call.  To  carry  the  value  of  a  variable  out  of  the  repeti¬ 
tion,  a  new  global  named  constant  must  be  created,  and  set  in  the  guarded  command 
that  terminates  the  repetition.  All  statements  after  the  do  must  then  use  the  new  glo¬ 
bal  named  constant  in  place  of  the  variable.  For  example: 

i  vir,  s  vir:  =n,  0; 

do  i>0  ->  i,  s:=i-l,  s+i  od; 

t:=s 

becomes  (ignoring  our  naming  convention) 

“loop”(n,0); 

t:=s2 


‘Toop”(i,s): 

if  i>0  ->  “loop”(i-l,s+i) 

D  non(i>0)  ->  s2:=s 

fi 

The  algorithm  sketched  shows  that  our  notation  is  at  least  as  powerful  as 
Dijkstra’s.  While  there  usually  is  a  more  natural  structuring  of  the  program  than  that 
generated  by  this  transformation,  the  length  of  the  program  will  increase  at  most 
linearly. 

This  transformation  underscores  how  parameters  carry  values  into 
refinements  and  global  named  constants  carry  values  out.  Since  we  have  adopted 
Dijkstra's  rule  that  the  statement  initializing  a  named  constant  be  statically  determin¬ 
able,  the  set  of  global  named  constants  set  by  a  particular  refinement  must  be  stati¬ 
cally  determinable.  In  a  recursive  call  then,  the  caller  delegates  its  responsibility  to 
initialize  global  named  constants.  This  delegation  is  total  since  the  caller  and  callee 
are  obliged  to  set  exactly  the  same  global  named  constants.  Moreover,  since  there  is 
no  other  result  a  refinement  can  produce,  once  the  named  constants  have  been  set, 
there  can  be  no  more  useful  work  for  the  refinement.  Thus,  all  recursion  in  our 
language  must  be  last  action  recursion! 

This  remarkable  consequence  shows  that  our  notation,  like  Dijkstra’s,  does 
not  have  the  expressive  power  of  Hehner’s.  We  cannot  write  recursive  calls  that  are  not 
last  action.  For  example,  we  cannot  rewrite  Hehner’s  recursive  factorial  program  in 
the  new  notation. 

Another  limitation  of  the  language  involves  the  static  naming  of  the  global 
named  constants  carrying  results  from  a  refinement.  Consider,  for  example,  the  calcu¬ 
lation  of  the  lowest  terms  of  the  ratio 

a  :  b  :  c 

The  result  would  be 

a-fd  :  b-i-d  :  c-rd  where  d  =  gcd(a,b,c) 
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Since  gcd(a,b,c)  =  gcd(a,gcd(bpc))  we  would  like  to  use  the  GCD  refinement  we  have 
already  developed.  Unfortunately,  this  involves  invoking  the  refinement  twice,  which 
would  cause  “g”  to  be  defined  twice,  contrary  to  the  rules  of  the  language. 

The  problem  is  that  the  global  named  constants  defined  by  a  refinement  are 
"wired  in".  A  refinement  can  then  only  be  called  once  during  the  lifetime  of  those 
named  constants.  Thus  general  purpose  refinements  cannot  be  written  and  used  freely 
in  the  language  as  it  is  defined  at  this  point. 


9.  Expression  Refinements 

What  constrains  all  recursion  to  be  last  action  and  all  refinements  to  be 
single-use  in  our  language  is  the  way  values  are  carried  out  of  a  refinement.  A  solution 
to  this  problem  is  to  introduce  expression  refinements  to  be  used  as  functions.  Syntac¬ 
tically,  calls  to  these  refinements  are  expressions.  The  body  of  an  expression 
refinement  is  an  expression  so  that  the  substitution  rule  makes  sense.  To  allow  expres¬ 
sion  refinements  to  be  composed  of  statements,  the  grammar  of  the  language  must  be 
involuted,  allowing  statements  within  expressions. 

To  ban  side  effects,  we  require  that  no  named  constant  initialized  within  an 
expression  be  global  to  the  expression.  A  sequence  of  statements  followed  by  an 
expression  denotes  the  value  of  the  expression  in  the  context  created  by  executing  the 
statement  sequence.  We  also  add  an  if  expression  in  the  obvious  way.  The  factorial 
function  can  now  be  written  as  an  expression  refinement: 

"[n^Oj  n!”(n): 

if  n=0  ->  1 

D  n>0  n  x  “$n^0$  n!"(n-l) 
fi 

Note  that  this  is  not  last  action  recursion:  the  multiplication  must  be  performed  after 
computing  “£ns?0]  n!"(n-l).  Note  also  that  this  refinement  (or  any  other  expression 
refinement)  may  be  called  more  than  once  within  a  scope. 

In  conventional  languages,  procedures  have  powers  beyond  those  of  side- 
effect-free  functions:  they  can  modify  global  objects  such  as  variables,  data  structures, 
and  files.  In  our  language,  however,  there  are  no  objects,  and  so  any  statement 
refinement  is  equivalent  to  an  assignment  of  some  function’s  result  to  a  global  named 
constant  (or  several  functions’  results  to  several  named  constants).  Therefore,  any  call 
of  a  refinement  can  be  rewritten  as  an  assignment  of  the  result  of  an  expression 
refinement.  Since  they  are  redundant,  we  drop  statement  refinements  from  the 
language. 

An  expression  refinement  does  not  require  inheritance  of  global  named  con¬ 
stants:  values  can  be  carried  in  as  parameters,  and  values  can  be  carried  out  as  the 
result.  We  therefore  eliminate  inheritance,  significantly  simplifying  the  language  [Wulf 
and  Shaw  73], 


10.  A  Sample  Program  Development 

Following  a  long  tradition  [Dijkstra  76,  Hehner  79,  van  Emden  79],  we  will 
develop  a  program  for  integer  exponentiation.  This  development  is  different  because 
non-last-action  recursion  is  used  as  an  intermediate  step,  easing  and  motivating  the 
invention  of  a  new  co-ordinate  in  the  state  space. 
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First  we  need  a  specification.  If  “xty”  is  to  be  mathematically  defined,  “x” 
must  not  be  zero  or  “y”  must  be  positive.  If  the  result  is  to  be  integral,  “y”  must  be 
non-negative  (or  “x”  must  have  an  integral  inverse,  but  we  will  ignore  this  special 
case).  The  problem,  then,  is  to  design 

“Kx*0  |  y>0)  &  y^G]  xty” 

Using  the  knowledge  that  “Oty”  is  zero  if  “y”  is  greater  than  zero,  we  can 
break  the  problem  into  two  cases: 

“Kx*0  I  y>0)  &  y^O]  xty”: 

if  x=0  &  y>0  ->  0 

D  x*0  &  y§0  ->  “$x*0  &  y^O]  xty”(x,y) 

fi 


(Note  that  this  refinement  is  distinct  from  the  one  it  calls  because  their  names  are  dis¬ 
tinct.) 

Given  “x^O”,  the  equations 
xtO  —  1 

xty  =  xx(xt(y-l)) 

lead  us  to  the  usual  recursive  definition: 

‘ix*0  &  y^O}  xty”(x,y): 
if  y=0  ->  1 

D  y>0  -»  x  x  “$x*0  &  y^Oj  xty”(x,y-l) 
fi 


These  refinements  perform  the  required  computation,  but  they  are  expensive 
to  execute  because  the  recursion  is  not  last-action.  As  written,  the  multiplication  must 
be  done  after  the  recursive  call  returns.  A  straight-forward  implementation  would 
create  a  stack  of  length  proportional  to  “y”. 

The  stack  preserves  a  number  of  pending  multiplications.  Right  after  the 
return  from  the  final  recursive  call  of,  say,  the  calculation  of  ”xt5”,  the  state  is  essen¬ 
tially: 


Xx(xx(xx(xx(xx(l))))) 

We  would  like  to  be  able  to  regroup  the  state  information  conceptually  to  be: 

((((( l)xx)xx)xx)xx)xX 

If  we  could  delegate  the  multiplication  to  the  called  refinement,  however,  the  call  would 
be  a  last-action  call.  We  could  then  perform  intermediate  multiplications,  thus  elim¬ 
inating  the  need  for  a  stack. 

If  partial  results  are  passed  down  to  successive  invocations,  instead  of  being 
returned,  we  can  effect  this  regrouping: 

”^x^0  &  y^Oj  xfy”(x,y): 

“£x*0  &  y^O^  zx(xty)”(x,y,l): 
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“fxs^O  &  zy(x1'y)”(x,y,z): 

if  y=0  ->  z 

D  y*0  ->  “Jxt*0  8c  y^O]  zx(xty)”(x,y~l,zxx): 
fi 


What  we  have  done  here  is  to  develop  a  last-action  recursive  refinement  from 
a  simpler  non-last-action  recursive  refinement.  We  examined  what  information  was 
implicitly  encoded  in  the  stack  and  instead  explicitly  represented  it  with  a  parameter. 
This  corresponds  to  the  invention  of  the  variable  "z”  in  Dijkstra’s  [76  p.  65]  and 
Hehner’s  [79  ps.  17]  derivations.  Our  development  seems  less  imaginative:  an  advan¬ 
tage  since  imagination  is  a  scarce  quantity.  Moreover,  our  derivation  could  not  have 
been  done  in  Dijkstra’s  language  (nor  in  our  earlier  language)  since  non-last-action 
recursion  is  needed. 


11.  Composite  Results 

Often  the  result  of  a  refinement  is  conceptually  a  composite  value.  For  exam¬ 
ple,  a  divide  refinement  might  return  both  a  quotient  and  a  remainder.  Since 
refinements  have  the  status  of  expressions,  we  allow  these  expressions  to  be  compo¬ 
site.  A  call  to  an  integer  divide  refinement  might  then  look  like: 

quot,  rem:="[x^0  &  y>0]  x-ry,  x  rem  y”(i,j) 

with  the  refinement  definition: 

"£x^0  &  y>0]  x-ry,  x  rem  y”(x,y): 
if  x<y  -»  0,  x 

D  x^y  -*  q,r:=“[x£0  &  y>0]  x-r y,  x  rem  y”(x-y,y); 
q+1,  r 

fi 

The  only  operations  we  allow  on  a  composite  value  are  to  assign  or  return  it. 

An  array  search  routine  represents  a  whole  class  of  search  routines  where 
composite  results  are  natural.  After  searching  an  array  for  a  particular  item,  it 
returns  a  Boolean  value  indicating  whether  the  item  was  found,  and,  if  so,  an  index 
value  indicating  where  it  was  found  in  the  array. 

To  establish  the  predicate 

P(a,x, index)  =  (found{a,x)  =>  (a[index]=x)) 
where  found(a.x)  =  (exists  i:  a[i]=x) 

we  define  the  refinement: 

“found(a.x),  index  [P(a,x,index)]”(a,x) 

It  should  be  noted  that  the  refinement  is  (very  naturally)  specified  using  a  postcondi¬ 
tion.  In  particular,  “index”  is  any  value  such  that  the  postcondition  P(a,x, index)  is 
satisfied. 

This  array  search  routine  points  up  a  problem  with  our  notation.  When  the 
item  is  not  found  in  the  array,  requiring  any  particular  value  for  “index”  would  be 
overspecification.  If  we  leave  “index”  undefined,  the  most  natural  approach,  then  the 
implication  operator  in  P  must  be  conditional.  A  more  serious  problem  is  that  we 
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would  be  moving  towards  making  undefined  a  legitimate  value  since  we  would  be  allow¬ 
ing  assignment  of  it.  The  possible  ways  around  this  problem  are  to  overspecify,  to  allow 
the  value  “undefined”,  or  to  allow  composite  values  to  be  elements  of  “union”  types. 
Considering  the  problems  "undefined”  causes,  we  prefer  union  types. 


12.  Implementation 

One  goal  in  the  design  of  Dijkstra’s  language  was  efficiency.  Have  we  lost 
efficiency  in  the  new  language? 

Hehner  showed  how  his  refinement  calls  could  be  implemented  efficiently  if 
they  were  last  action.  Since  all  do  loops  can  be  transformed  into  last  action  recursive 
refinements,  no  inefficiency  was  incurred  by  replacing  the  do. 

We  eliminated  the  variable  and  added  a  parameter  mechanism  to  replace  it. 
Passing  a  parameter  has  the  effect  of  assigning  the  actual  parameter  to  the  formal 
parameter,  and  as  such  should  cost  no  more  than  any  similar  assignment. 

The  principal  implementation  problem  of  the  language  is  that  the  cost  of 
passing  or  assigning  a  large  value  such  as  an  array  is  potentially  high.  For  just  this 
reason,  Dijkstra  introduces  an  array  assignment  shortcut,  allowing  an  array  variable  to 
be  modified  instead  of  being  completely  re-assigned  [Dijkstra  76  chapter  11].  Since 
our  language  has  no  re-assignment,  we  can  hardly  solve  the  problem  by  making  re¬ 
assignment  more  efficient.  Instead  we  are  forced  to  pass  large  values  as  parameters. 

A  variety  of  implementation  methods  can  be  applied  to  allow  large  values  to 
be  handled  efficiently.  These  methods  depend  on  the  usage  patterns  of  the  values.  For 
example,  a  large  value  can  always  be  passed  by  reference  instead  of  by  value,  involving 
only  the  copying  of  its  address.  This  technique  is  most  useful  when  the  called 
refinement  does  not  create  a  new  large  value  that  is  just  a  small  modification  of  the 
original.  More  powerful  methods  involving  data-flow  analysis  and  "lazy  evaluation” 
[Henderson  76]  are  being  investigated. 


13.  Relation  to  Pure  LISP 

Although  this  language  evolved  from  Dijkstra’s,  it  in  fact  is  very  close  to  being 
a  subset  of  pure  LISP.  Our  recursive  refinement  mechanism  has  no  powers  beyond 
those  of  LISP’s  recursive  functions,  and  our  expressions  can  easily  be  transformed  into 
LISP.  Our  assignment  statement  can  be  translated,  albeit  a  bit  clumsily: 

x  :=  e;  <statements> 


becomes 


(lambda  (x)  (Ctranslated  statements>))  Ctranslated  e> 

(Dijkstra’s  and  Hehner’s  re-assignment  cannot  be  handled  this  way.)  Our  if  statement 
must  be  changed  to  an  if  expression,  and  then  it  can  be  expressed  directly  as  a  LISP 
cond  expression.  These  transformations  are  straightforward,  but  often  produce  a  pro¬ 
gram  that  is  hard  to  read. 

Our  language  is  not  even  as  powerful  as  pure  LISP.  We  have  provided  no  way 
of  manipulating  functions  as  values  in  their  own  right,  a  major  feature  of  LISP.  We  have 
no  inheritance,  and  so  no  “funarg  problem”  (the  question  of  dynamic  or  static  scope 
rules).  Thus  some  of  the  more  sophisticated  (read  “trickier”)  LISP  programs  cannot 
be  written  in  our  language. 
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Our  language  is  semantically  a  subset  of  both  LISP  and  ALGOL.  As  such  it  is  a 
bridge  between  the  two  cultures.  We  have,  in  effect,  shown  how  Dijkstra’s  philosophy 
and  methodology  can  be  carried  over  to  LISP.  Perhaps  work  of  the  LISP  community 
can  be  carried  back.  More  significantly  we  have  found  a  common  ground  that  is 
simpler  than  either  Dijkstra’s  language  or  LISP. 


14.  Conclusion 

The  concept  of  the  variable,  central  to  most  programming  languages,  has 
been  eliminated.  Although  this  is  a  drastic  change,  it  does  not  seem  to  adversely  affect 
Dijkstra’s  methodology.  As  a  result,  learning  to  program  in  the  new  notation  need  not 
be  difficult. 

Efficient  execution  of  the  language  will  require  better  techniques  for  handling 
large  values  such  as  arrays  and  files. 

By  modifying  Dijkstra's  language,  we  have  simplified  the  semantics  consider¬ 
ably  and  made  more  static  properties  of  programs  manifest.  At  the  same  time  we  have 
increased  the  language’s  expressive  power.  Our  refinement  naming  convention  allows  a 
new  verification  technique. 
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CSRG-93  A  DEVICE-INDEPENDENT, GENERAL-PURPOSE  GRAPHICS  SYSTEM 
IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 
William  T.  Reeves,  August  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-94  ON  THE  AXIOMATIC  VERIFICATION  OF 
CONCURRENT  ALGORITHMS 
Christian  Lengauer,  August  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-95  PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1978 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis,  EE,  August  1978] 

CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 
TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

[M.Sc.  Thesis,  CSRG,  October  1978] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  I.  Vanek,  February  1979 

CSRG-100  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 

CSRG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.),  May  1979 

CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.R.  Hehner,  May  1979 

CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  July  1979 
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